Hacker's Arsenal - The Cutting Edge of Hacking/Hacker's Arsenal - The Cutting Edge of Hacking.iso/texts/misc/auditing.txt

Text File | 2001-07-11 | 13.4 KB | 235 lines

        An approach to systematic network auditing
       ============================================

   Security papers - members.tripod.com/mixtersecurity/papers.html

In the past few years, people have learned that a well concepted network
installation done by administrators with average knowledge of security could
still very often be compromised due to the large amount of possibilities
to attack and discovered vulnerabilities an intruder nowadays has at his
disposal. This is the cause why recently security auditing and penetration
testing has become popular for big companies, security-aware individuals and
of course the security industry. Network auditing, or penetration tests can
be seen as a systematic attempt to gain access to a network by discovering
all points of access to it, and then analyzing those points for any known
vulnerabilities, which a real intruder could use to gain further access.
However, many companies are performing this kind of analysis in a manner,
which is really not sufficient and systematic enough to spot all possible
vulnerabilities. So, here is one possible approach, in a nutshell, that
I would take to secure a network systematically.

_______________________________________________________________________________

1. Starting off with a secure network

The main pre-requirement for having a secure network is to start off with
installations of which you can be sure that no security intrusion has
previously happened. Imagine a big company severely securing their
resources, only to find they have been compromised a year before, and the
attacker has changed the system kernel so he doesn't require any vulnerable
program at all to gain access anymore. There hasn't even to be a permanently
open tcp or udp port; if the intruder is clever, he had reprogrammed the
system to watch for raw data containing secret activation code, and then
give backdoor access for a very short period of time, that cannot be detected
unless one knows the correct code. Take a look at the Q [1] remote shell, if
you need an example.

So, first of all, (re-) install your operating systems, making sure that
there is are no binary executables left from old installations. Importing
other kind of data from other systems generally creates no security risk.
If you are open-minded enough to take an advice on what OS to use, then let
me suggest anything except Windows NT. Systems like HPUX/AIX/IRIX are no good,
either, because they are not open source. The problem is that you CANNOT
trust systems that come without their source code to be secure at all. The
vulnerabilities which exist in the software and kernel of commercial non-
open-source systems are not worse than those in other systems, but they EXIST,
and it is very hard for the security community to identify them, and it takes
alot more time. For an example, SunOS / Solaris was always said to be very
secure, until recently its creators decided to make the source code public
(which was a good idea in long-time measures). Quickly, a huge lot of
vulnerabilities  that couldn't be detected before were found in Solaris, and
some people still consider it to be extraordinary secure... this was the right
step on becoming a secure operating system, but it will surely take a long time
until virtually all vulnerabilities have been spotted.

If you want a secure operating system, install a BSD derivate, such as OpenBSD.
You can also use Solaris, or Linux if you have sufficient knowledge of securing
it. The most problematic thing is, that it has become very easy to install even
a complex UNIX system, and that many people only do enough to get it up and
running. You should get a system that is at least one year old, or older, to
make sure that most of the vulnerabilities present in the system have already
been spotted - this is important, the people who always install the newest
version of their systems, one day after they come out, put their security at
risk worse than people who run outdated, but well-patched systems.
Secondly, go to your vendors web site and inform yourself about which
software packages you should update. Regarding security purposes, it is only
important to update packages that are suid root, always run as root, and
servers that you generally need and run.

Next, disable any servers that run by default and that you won't explicitly
require on your network! Browse through your files, looking for suid binaries:
find / \( -perm -4000 -o -perm -2000 ! -type d \) -exec ls -ldb {} \;
Remove the suid flag (chmod 755 each binary) on any of the programs that
don't need to be run by non-root users / scripts with root privileges.
Now you need to examine your system and server configuration, most of it
is in the /etc directory. Get to know your operating systems security
mechanisms, and also recompile your kernel. You should have basic knowledge of
every server / daemon process that you run on your machines, and check the
configuration for it. Once you have done all this, you can consider to have
a system with basic stability and security present. Also consider doing this
on one system and copying your partitions to other systems to save yourself
some work.

One more recommended thing is to block ICMP at your border router(s),
to be safe from ICMP 'firewalking' and generic denial of service.
To prevent 'smurf' and other flood attacks, specifically make sure your
broadcast addresses do not reply to ICMP (IPs ending in .0 and .255), and
(if you use IOS or something similar), make your routers detect 'flood' attacks
and go into high-bandwidth or alternative-route modes if they detect a certain
amount of packets in a specified amount of time. Connection-oriented routing
can also be very useful. Finally, deny all other known and unknown IP protocols
besides TCP, UDP and ICMP, in case you don't need them.

_______________________________________________________________________________

2. Creating reliable audit trails

One simple precaution that everyone should take is to make sure that
audit trails (in other words: logs) are present, and one instance of them
cannot be altered. Compile a list of servers that you don't (!) and never
will run on any of the machines on your network, and instruct your border
routers that connect you with the rest of the world, to deny and log all
incoming requests to those ports. Don't block port 20 unless you want to
break active ftp transfers, and don't block ports above 1024 (non-privileged).
You should have some instance of remote logging available, that each of
your hosts uses. The easiest way is to configure syslog (see syslog.conf
manpage) to log all messages to a remote loghost. A loghost is a dedicated,
secured machine that runs only syslog and sshd (or not even sshd, so it is
accessible only physically via console) and has enough disk space for all the
logs. A good idea would also be a solution with digitally signed and/or
encrypted logs to prevent manipulation and to ensure authenticity.
Once you have done this, you can implement extra Intrusion Detection and
firewalling services. This is recommended as extra security mechanism, but
not required, if you have really secured your machines well, and a bit too
much to cover it all in one article.
Only this much: If you implement a firewall/IDS, then first perform step 3,
install the firewall with a good rule set and perform step 3 again to audit
your firewall rules and your IDS stability and logging capabilities.

_______________________________________________________________________________

3. Penetration testing I: gathering information

Now, let us find every available service. If this step is performed before
implementing a firewall, it should be performed from within the local
network, to be as reliable as possible, else from behind the network border.
You should use nmap [4] for port scanning, which is currently the most
reliable and comprehensible way of port scanning available. Scan tcp port
range 1 to 65535 and udp port range 1 to 65535 on every host, and save the
results (open ports). This would look like, for example:

nmap -sT -P0 -p1-65535 -I -n 10.0.0.0/24 >> results.txt
nmap -sU -P0 -p1-65535 -I -n 10.0.0.0/24 >> results.txt
(This would scan hosts 10.0.0.0 to 10.0.0.255.)

Note: to audit firewall rules or IDS logging capabilities, re-run this
scan with values like: -f, -sS / -sF / -sN and -g 20 / 53 / 80
The results should NOT show more than normal scans, and an eventually
installed IDS should detect and log the stealth scanning tricks.

_______________________________________________________________________________

4. Penetration testing II: evaluating information

Generally, the causes of remote network security problems
can be classified into five groups:

I. Problems due to buffer overflows (ex.: exploitable imap server)
II. Problems due to generally insecure programs (ex.: insecure CGI scripts)
III. Problems due to insecure configuration (ex.: default samba shares)
IV. Problems due to lack of or insecure passwords (ex.: SNMP daemon)
V. Backdoors and trojan horses (not applicable if you went through step 1.)

Many people see a penetration check as an attempt to exploit any of these
problems, if present, to gain access (hack) into a host and therefore prove
that it is insecure. This is not sufficient to ensure the security in a
systematical way, however, because one would omit the potential holes.

One way to start off, is using a well-designed and reliable security scanner,
like NSAT [5]. I don't only recommend it because of self-promotion ;), but
because it scans for a lot of vulnerabilities and does not only report them,
but rather a lot of information, versions, auditing results etc. out of which
one can draw its own conclusions. In contrary to many other scanners, this
enables NSAT to audit services at all times with maximum efficiency, while
it doesn't need to maintain a very recent vulnerabilities database. Give NSAT
a try and audit the services it scans for with it. However, if you run other
uncommon services, that NSAT does not scan for, or you want to be 100% safe
you should afterwards scan and examine them manually as well, using
telnet, netcat, browser, etc. sessions.

To actually identify all vulnerabilities, (you may have guessed it, this is
the hardest part :)!), search archives of security mailing lists [8],
security sites [9], and vendor sites for known security issues regarding the
server, and also don't be afraid to write the author to ask if your version
is vulnerable. If you find no exploits or advisories regarding your program
at all, you can consider it to be secure. The better way is of course, to
search updates for every server you run and install the latest versions.
Retain from running anything if you don't fully understand how to configure
and maintain it. In most cases, understanding a program up to the point where
you know how to properly secure it, doesn't take too much work, as most
GNU programs are generally well-documented and user friendly once you get
to know them.

There are a few examples, where you can not audit services satisfyingly
by looking at the version or performing sample sessions, namely httpd,
where you have to locally examine the CGI scripts. You can use very
sophisticated and flexible CGI scanners to locate vulnerable CGI's,
but you can never be sure to find all by doing a remote scan. You need
to locally scan your cgi-bin/ directory and scripts that may reside
somewhere else in your document root. A big security risk are self-written
or uncommon CGI scripts, an intruder WILL scan and find those, if he
tries hard enough. Always consider every executable script on your HTTP
server as relevant to security as a separate server running with the
privileges of your httpd.

Another important subjects are services with password authentication.
If possible, disable non-encrypted services and use kerberos-enabled
mail servers, and ssh / sftp instead. It is crucial to your security to
have all authentication mechanisms use strong, non-standard passwords that
cannot be easily brute forced. Configuring your standard authentication
not to take weak passwords at all is a good idea. If you are securing multi-
user systems, you should always make secure passwords a central point in your
security policy. (But designing an adequate security policy is another big,
important topic besides network security.) BSD style MD5 and all DES passwords
can and should be tested with John [6]; other issues with passwords exist in
snmp, http auth, linuxconf, r-services, SQL and various other services.

_______________________________________________________________________________

A small collection of related articles and programs

[1] Q - stealth encryted remote shell and redirection server
    http://members.tripod.com/mixtersecurity/Q-0.9.tgz
[2] Brian Martin: Why your network is still vulnerable
    http://www.hackernews.com/orig/whyvuln.html
[3] David Curry: Improving your network by breaking into it
    http://www.rootshell.com/beta/docs/improving_security_sri.ps.gz
[4] Nmap by fyodor
    http://www.insecure.org/nmap
[5] Network security analysis tool
    http://members.tripod.com/mixtersecurity/nsat-1.09.tgz
[6] John the ripper by Solar Designer
    http://www.false.com/security
[7] Daniel V. Klein: Foiling the Cracker
    http://www.rootshell.com/beta/docs/passwords_klein.ps.gz
[8] Security Focus / Bugtraq Mailing List archives
    http://www.securityfocus.com
[9] Packet Storm Security
    http://packetstorm.securify.com

_______________________________________________________________________________

Mixter <[e-mail]>
http://members.tripod.com/mixtersecurity